-3 



ATTORNEY DOCKET: 134143 



5 



Nonprovisional Patent Application 
of 

10 MICHAEL S. WENGROVITZ 

for 

CLIENT-BASED INTEGRATION OF PBX AND MESSAGING SYSTEMS 



15 FIELD OF THE INVENTION 

The present invention relates to a technique for integrating one or more user interfaces 
, with a PBX phone system. In particular, the invention relates to a method and system for 

i 

providing off-hook/on-hook presence notification for a PBX phone, establishing media 
sessions concurrent with PBX telephonic communication, customized call treatment for a 
20 PBX phone, call transfer capability between a PBX phone and numerous other devices, 
and PBX call control. 

BACKGROUND 

Private Branch Exchange (PBX) telephone systems are used in many businesses to enable 
25 workers to make and receive calls from the Public Switched Telephone Network (PSTN) 
and other PBX phones within the enterprise. PBX systems also provide a host of 
telephonic services to the enterprise workers including call forwarding, transferring, 
conferencing, voice mail, personalized greetings, and the like. 

30 In many cases, an enterprise worker's phone resides on the desktop in immediate 

proximity to the worker's personal computer. The personal computer may provide tools 
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for word processing, viewgraph editing, email, and web browsing, as well as other 
communications tools such as instant messaging, buddy lists, presence, video, and other 
tools for collaboration. Instant messaging allows people with network access to send text 
messages and other media to other individuals listed in a buddy or contact list. An instant 
5 text message is sent in near-real time to a contact where it is then displayed in a graphical 
user interface window within the context of an on-going text-based conversation. In 
addition to text messages, instant messaging may also be used within chat sessions and 
custom chat rooms where friends or co-workers can interact and share media. Some 
instant messaging applications are also enabled with a presence protocol used by a one 
10 person to determine whether a buddy or contact is "present" online and to subscribe to 
changes in the presence state or information. 

Despite the prevalence of PBX phones and communications-enabled personal computers 
in the enterprise, there is an absence of sufficient integration between these two types of 

15 communication systems. For example, an enterprise worker's instant messaging 

application may be aware of the worker's online presence but is oblivious to the worker's 
telephonic presence, i.e. buddies do not know that a worker is occupied on his PBX 
phone. Or, as a second example, although a worker sets up a voice session to another 
worker by dialing a PBX extension, an entirely separate process must be followed to 

20 setup a session for exchanging a document. Therefore, there is a need for a solution that 
integrates the PBX system and communications applications on enterprise workers' 
computers to provide greater interoperability, simplified PBX control, and enhanced 
sharing and collaboration. 

25 SUMMARY 

The invention in its several embodiments features a method and system for using a 
computer interface to perform off-hook/on-hook presence notification for a PBX phone, 
establish media sessions concurrent with PBX telephonic communication, execute 
custom call treatment in conjunction with a PBX phone, implement call transfer 
30 capability between a PBX phone and numerous other devices, and provide PBX call 
control. The PBX is generally enabled with computer telephony integration (CTI) 
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capabilities and may also, depending on the embodiment, be enabled with Voice-over- 
Internet Protocol (VoIP) capabilities such as Session Initiation Protocol (SIP). The 
computer interface may be any number of computer appliances including personal 
computer also enabled with CTI, for example. 

5 

In one embodiment, the invention relates to a presence notification method for 
communicating an enterprise worker's on-phone/off-phone presence state to other 
workers using a computer interface operatively coupled to a system comprising a private 
branch exchange (PBX) and a first PBX phone. The presence notification method 
10 preferably comprises the steps of: receiving from the PBX a first message indicating an 
off-hook state of the first PBX phone; consulting a subscriber table including the identity 
of one or more presence-state subscribers; and transmitting a second message to at least 
one of the one or more presence- state subscribers indicating the off-hook state of the first 
PBX phone. 

15 

In a second embodiment, the invention relates to a method for establishing a collateral 
communication session between a plurality of enterprise workers' computer interfaces in 
response to a call between the workers. The collateral communication session, referred 
to herein as a concurrent media session, may take a number of forms including text 

20 messaging, document exchange, desktop sharing, and video, for example. The method 
for establishing concurrent media session setup using a first computer interface 
operatively coupled to a system comprising a private branch exchange (PBX) and a 
second computer interface preferably comprises the steps of: receiving from the PBX a 
first message signifying that the second PBX phone has called the first PBX phone; 

25 transmitting a second message from the first computer interface to the second computer 
interface requesting a media session; determining whether the media session request has 
been accepted at the second computer interface; and establishing a media session between 
the first computer interface and second computer interface if the session request message 
is accepted. 

30 
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In a third embodiment, the invention relates to a method for performing custom call 
treatment allowing a recipient of an incoming PBX call to respond to the call by 
transferring the call to another device or responding with an instant message, for 
example, depending on various factors including the caller, the time, and date. The call 
5 treatment method in a first computer interface operatively coupled to a system 

comprising a private branch exchange (PBX) and a first PBX phone preferably comprises 
the steps of: receiving from the PBX a first message indicating an incoming call; 
determining from a call routing table maintained by the first computer interface an 
incoming call response to the incoming call; and transmitting a group of one or more 
10 messages based on the incoming call response, wherein the group comprises a second 
message answering the incoming call. 

In a fourth embodiment, the invention relates to a method for transferring a call between 
an enterprise worker's PBX phone and an associated computer interface. The call 

15 transfer method in a first computer operatively coupled to a system comprising a private 
branch exchange (PBX) and a first PBX phone, preferably comprises the steps of: 
transmitting to the PBX a first message for transferring a telephone call associated with 
the first PBX phone; establishing a voice-over-IP session between the PBX and the first 
computer; and replacing the telephone call to first PBX phone with a call to the first 

20 computer via the voice-over-IP session. 

In a fifth embodiment, the present invention relates to a method of controlling PBX 
telephone calls to a worker's PBX phone using a computer interface operatively coupled 
25 to a system comprising a PBX and a first PBX phone. The PBX call control method 

preferably comprises the steps of: receiving from the PBX a first message indicating the 
presence of a telephone call associated with the first PBX phone; and transmitting to the 
PBX a call control message, such as a call-hold command, or call-forwarding command 
directing the PBX to another PBX phone or VoIP client, for example. 

30 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example and not limitation in the figures of 
the accompanying drawings, and in which: 

FIG. 1 is a functional block diagram of an enterprise network including a PBX system 
5 and Internet Protocol (IP) network, according to the preferred embodiment; 

FIG. 2A is a functional block diagram of a PBX, according to the preferred embodiment; 
FIG. 2B is a functional block diagram of a PBX processing module, according to the 

preferred embodiment; 
FIG. 3 is a functional block diagram of a PBX user phone, according to the preferred 
10 embodiment; 

FIG. 4A is a functional block diagram of a enterprise worker's PBX-Messaging 

Integration Client (PMIC), according to the preferred embodiment; 
FIG. 4B is a functional block diagram of a PMIC processing module, according to the 
preferred embodiment; 
15 FIG. 5 A and 5B is a state diagram characterizing the PBX with which the preferred 
embodiment interoperates, according to the preferred embodiment; 
FIG. 6 is a flowchart of the PBX external-call-placed processing, according to the 

preferred embodiment; 
FIG. 7A is a flowchart of the PBX internal-call-placed processing, according to the 
20 preferred embodiment; 

FIG. 8 is a flowchart of the PBX voice-over-IP (VoIP) session setup, according to the 

preferred embodiment; 
FIG. 9 is a flowchart of the PBX call-receiving state processing, according to the 
preferred embodiment; 
25 FIG. 10 is a flowchart of the PBX call-answered state processing, according to the 
preferred embodiment; 
FIG. 1 1 is a state diagram characterizing the PBX-Messaging Integration Client (PMIC) 

processing, according to the preferred embodiment; 
FIG. 12A is a flowchart of the on-phone presence state processing, according to the 
30 preferred embodiment; 
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FIG. 12B is a flowchart of the off-phone presence state processing, according to the 

preferred embodiment; 
FIG. 13 is a flowchart of the concurrent media session setup procedure, according to the 

preferred embodiment; 

5 FIG. 14 is flow diagram depicting the method of distributing telephonic presence-sense 
notices, according to the preferred embodiment; 
FIG. 15 is a flow diagram demonstrating the use of a networked intermediate server with 
which the PBX and one or more PMICs may interoperate, according to the preferred 
embodiment; 

10 FIG. 16A is a flow diagram demonstrating the procedure for establishing a first category 
of CMS between calling parties, according to the preferred embodiment; 
FIG. 16B is a flow diagram demonstrating a first procedure for establishing a second 
category of CMS between calling parties, according to the preferred embodiment; 
FIG. 16C is a flow diagram demonstrating a first procedure for establishing a third 
15 category of CMS between calling parties, according to the preferred embodiment; 

FIG. 17 is a flow diagram demonstrating a call initiated from the PMIC, according to the 

preferred embodiment; 
FIG. 18A is a flow diagram demonstrating an on-going telephone communication being 
transferred from a user PBX phone to an associated PMIC, according to the preferred 
20 embodiment; 

FIG. 18B is a flow diagram demonstrating an on-going telephone communication being 
transferred from PMIC to an associated PBX phone, according to the preferred 
embodiment; 

FIG. 19 is a flow diagram demonstrating a PMIC automatically answering an incoming 
25 call, according to the preferred embodiment; 

FIG. 20A is a flow diagram demonstrating an incoming call being automatically 

forwarded by a PMIC, according to the preferred embodiment; 
FIG. 20B is a flow diagram demonstrating a PMIC automatically responded to an 
incoming call with an instant message, according to the preferred embodiment; 
30 FIG. 21 is a functional block diagram of a PMIC with a plurality of selectable SIP user 
agents, according to the second preferred embodiment; and 



6 



FIG. 22 is a CTI server with a plurality of PBX interfaces, according to the preferred 
embodiment. 

DETAILED DESCRIPTION 

5 FIG. 1 is a block diagram of a PBX system operably coupled to a data network. The 
PBX system 100 comprises a PBX 110 and a plurality of PBX phones 130-132, each 
phone being associated with a unique extension number. The PBX 110 manages calls 
between the plurality of user phones 131-133 and a set of trunk lines operably coupled to 
the Public Switch Telephone Network (PSTN) 102 while supporting call forwarding 
10 between PBX phones, conference calling, call holding, voice mail, personalized 
greetings, and the like. The PBX system 100 is consistent with both new telephone 
systems and a vast number of legacy telephone systems currently located at and operated 
by enterprises today. 

15 Also operating within the enterprise is a data communications network 150 embodied in 
or operably coupled to a local area network (LAN), a wide area network (WAN), a 
metropolitan area network (MAN), the Internet Protocol (IP) network 104, or a 
combination thereof. The communications network 150 operably couples a plurality of 
computers enabled with a PBX-Messaging Integration Client (PMIC) 140-142 distributed 

20 throughout the enterprise to each other and to the resources available through the World 
Wide Web using Ethernet and or the transmission control protocol (TCP)/IP protocol 
suite. Each of the PMICs 140-142 is generally associated with an individual enterprise 
worker. In most cases, an individual's PMIC is located in the immediate proximity to the 
individual's phone, thus giving rise to a logical association between a user PMIC and a 

25 user phone. The logical association between a PMIC, a phone, and a single user exist for 
a multiplicity of enterprise workers including a first user 120, second user 121, and third 
user 122, and so on. 

In the preferred embodiment, the PBX 1 10 is enabled with a computer telephone 
30 integration (CTI) protocol, which refers to a signaling convention by which the PMICs 
140-142 may control and monitor PBX functions. In the preferred embodiment, the 



7 



PMICs 140-142 are adapted to act as individualized clients for: (1) placing and 
answering PBX calls without a PBX phone, (2) routing incoming call directed PBX 
extensions to other devices, (3) forwarding calls away from PBX phones to other devices, 
and (4) placing calls on hold. In addition to receiving CTI commands, the PBX or the 
5 CTI client associated thereto is also adapted to transmit CTI messages upon occurrence 
of certain events, as is described in greater detail below. Also in the preferred 
embodiment, the PMIC provides an interface to presence, instant messaging, document 
exchange, desktop sharing and other capabilities typically resident in applications such 
Microsoft's Real-Time Communications (RTC) Messenger. 

10 

FIG. 2 A represents a functional block diagram of the PBX 110 with which the enterprise 
PMICs 140-142 intemperate. The PBX 1 10 generally includes a cabinet or backplane 
including one or more trunk interfaces 220 for converting between the signal format and 
voice transmission of the PSTN 102 and the internal convention used by the PBX system 

15 100, a plurality of PBX phone interfaces or line cards 222 providing a connection to the 
user PBX phones 130-132, a CTI interface 224 for transmitting and receiving CTI 
messages transmitted via the network 150, and a switch controller 202 for creating and 
managing voice circuits between the trunk interfaces 220, line cards 222, and CTI 
interface 224. The switch control 202 is generally an element of a processing module 

20 200 embodying various call management services 204 including voice mail 206 and other 
interactive voice response (IVR) systems 208, for example. 

Signaling and voice communications between the PBX 110 and phones 130-132 are 
conventionally performed using a digital protocol, although an analog protocol may also 

25 be employed. The digital protocol, referred to herein a private digital signaling and voice 
(PDSV) protocol, comprises a signaling convention that includes operation-codes used to 
exchange voice communications as well control signals. Although well understood by 
those skilled in the art, PDSV protocols are generally proprietary implementations and 
differ between vendors. The major CTI standards are Telephony Application 

30 Programming interface (TAPI) and Telephony Services Application Programming 

Interface (TSAPI), as well as the European Communications Manufacturers Association 
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(ECMA) standard for CTI, namely the Computer Supported Telecommunications 
Applications (CSTA) protocol. 

Illustrated in FIG. 2B is a functional block diagram of a PBX processing module 200. 
5 The PBX processing module 200 in the preferred embodiment incorporates one or more 
software and or firmware components that cooperate with switch control 202 to provide 
the PBX services 204. The PBX processing module 200 may include an operating 
system 232, e.g. UNIX-based system or proprietary implementation, that in turn supports 
a CTI message handler 234 adapted to generate and respond to various CTI commands in 

10 the manner set forth in greater detail below. When a CTI registration command is used to 
associate a PBX with a PMIC, for example, the CTI message handler 234 is adapted to 
transmit various event messages to the PMIC is response to various types of activities 
involving one or more PBX phones. In particular, the CTI handler 234 in the preferred 
embodiment is adapted to transmit a CTI off-hook event to a registered PMIC in response 

15 to an off-hook signal received from the associated PBX phone, transmit a CTI on-hook 
event to a registered PMIC in response to an on-hook signal from the associated PBX 
phone, transmit a incoming-call event to the PMIC associated with a PBX phone to 
which the PBX transmits a ring signal, a first call-answered event to the PMIC when the 
associated phone is used to answer an incoming call, and transmit a second call-answered 

20 event to the PMIC associated with the PBX phone used to place a call to another PBX 
phone when it is answered. 

Illustrating in a FIG. 3 is a functional block diagram of a PBX phone typical of user 
phones 130-132. The user PBX phone preferably includes a handset and base unit 300 

25 comprising a phone microprocessor module 310 that enables incoming and outgoing 
calls. The phone microprocessor module 310, in combination with the user interface 
logic 316, transmits input from the dial pad 314 and display relevant information at 
display 312. The phone microprocessor module 310, in cooperation with coder/decoder 
322, conveys incoming voice signals to an audio user interface (AUI) 320 speaker and 

30 outgoing voice signals received at an AUI 320 microphone to the PDSV interface 330. 
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Illustrated in FIG. 4A is a functional block diagram of a user's PMIC140-142. The 
PMIC 400 generally includes the hardware and software necessary to provide access to 
and exchange voice and control signals with another VoIP client including, in some 
embodiments, the PBX 110. In particular, the PMIC 400 comprises a processing module 
5 410, display 440, tactile user interface 450 preferably including a keyboard, a AUI 460 
with sound card and speaker, and a network interface card (NIC) 470 operably coupled to 
the data communications network 150. 

The processing module 410 generally comprises hardware components including a 
10 central processing unit 412, computer memory 414, and random access memory (RAM). 
As illustrated in FIG. 4B, the processing module 410 may further comprise software and 
or firmware components including a PMIC controller 428 and a PMIC graphical user 
interface (GUI) 434 used by the enterprise worker to monitor and configure the PMIC 
428 as well as bridge between the PBX domain and the VoIP domain. The PMIC 428 in 
15 the preferred embodiment is adapted to monitor calls involving a PBX phone 130-132, 
intervene in calls under certain circumstances in a manner defined by the user, and 
establish media sessions on behalf of an enterprise worker in parallel with a telephone 
call. 

20 Upon receipt of an incoming call, the PMIC 428 generally consults routing logic 430 to 
whether to forward an incoming call to another PBX phone or other device, for example, 
or respond with a message transmitted via the network 150. In the process of monitoring 
calls involving a user's PBX phone, the PMIC 428 may consult the subscriber table 432 
to identify any Instant Messaging (IM) buddies in a contact list of changes in the 

25 enterprise worker's telephonic presence. In some circumstances, the PMIC 428 may also 
consult the concurrent media session (CMS) handler 434 to initiate transmission of an 
instant message, text chat or other voice and/or video media session between the PMICs 
of the users that are engaged in telephonic communication. 

30 PMIC processing module 410 further comprises a CTI client 422, preferably a CTI 

protocol stack, and Real-Time Communications (RTC) client 426 running on top of an 
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operating system 418 such MS WINDOWS also by Microsoft Corporation. The CTI 
client 422 together with its CTI application programming interface (API) 420 provides 
the underlying functionality used to implement the various call control functionality 
embodied in the PMIC processing of the preferred embodiment. The RTC client 426 
5 with RTC API 426 provides support for the Session Initiation Protocol (SIP) used in 
some embodiments to enable the CMSs, as discussed in greater detail below. 

Although the PMICs 140-142 in the preferred embodiment are personal computers, one 
skilled in the art will appreciate that any of a variety of processing devices including 
10 desktop computers, laptop computers, personal digital assistants (PDA), Internet-enabled 
appliances, or mobile communication devices such as cellular phones may be adapted for 
purposes of this invention. 

Illustrated in FIGS. 5 A and 5B is a state diagram characterizing the PBX with which the 
15 preferred embodiment interoperates. The PBX 1 10 generally monitors (state 502) the 
trunk lines to PSTN 102 as well as the internal phones 130-132. The operation of the 
PBX 1 10 characterized by the method of FIGS. 5 A and 5B generally falls into at least 
one of three different categories, namely, an outgoing call placed by a PBX user phone 
130-132 to a device external to the PBX 1 10, a internal call placed by a user phone 130- 
20 132 to another phone 130-132 within the PBX 1 10, and or an incoming call to a user 
phone 130-132 from a device external to the PBX 110. 

When a call is initiated by a user phone 130-132, an off-hook signal is transmitted from 
the phone to the PBX 1 10 with "digits" or dual-tone multi-frequency (DTMF) signals 

25 representing a phone number or a PBX extension number. If the off-hook signal 520 is 
accompanied by the phone number to an external phone, the PBX 110 transitions to an 
external call-placed state 504, illustrated in greater detail in the external call process 600 
of FIG. 6. Referring to FIG. 6, the PBX 1 10 identifies the digits representing external 
phone number received (step 610) from user phone and transmits (step 620) a connection 

30 request out to the PSTN 102. Since the preferred embodiment of the PBX 1 10 is enabled 
with CTI, the PBX also transmits (step 630) off-hook plus dialed-number events to the 
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associated caller's computer 140-142 via the IP network 150. The off-hook and dialed- 
number events are messages used to notify a device registered with the PBX, i.e. the 
caller's PMIC, that user phone has transitioned from on-hook to off-hook to make the 
call. In the preferred embodiment, a client on the network 150 must have registered for 
5 the notification at the PBX 110 using a registration event, e.g. a CTI message, requesting 
notifications about the state of user phone 130-132 identified by its extension number. 
Once registered, the PBX 110 directs the off-hook plus dialed-number events registered 
client. 

10 Referring again to FIG. 5A, if the off-hook signal 530 is transmitted from the PBX phone 
130-132 is accompanied by an extension number of a PBX phone 130-132 within the 
PBX 110, the PBX transitions to an internal call-placed state 506 illustrated in greater 
detail in the internal call process 700 of FIG. 7. Referring to FIG. 7, the PBX 1 10 
identifies the extension number received (step 710) from user phone and transmits (step 

15 720) a ring signal to the call recipient's phone. The PBX also transmits (step 730) an off- 
hook plus dialed-number event with the recipient's extension number to the caller's 
PMIC 140-142 via the IP network 150. The off-hook dialed-number event is preferably a 
CTI message, used to notify the caller's computer that caller's phone is now in the off- 
hook state as well as the particular extension dialed. In the preferred embodiment, the 

20 off-hook plus dialed-number event including the extension is transmitted indirectly from 
the PBX 1 10 through a CTI Server to the caller's computer, although the PBX may be 
used to directly transmit the event to the caller's PMIC. 

Referring to FIG 5 A, if the PBX 1 10 receives an answered signal 522 from the external 
25 call recipient, the PBX transitions from the external call-placed state 504 to the PDSV 
voice communication state 510. Similarly, an off-hook signal 532 from the call recipient 
in response to the internal call-placed 506 will also cause the PBX 1 10 to transition to the 
PDSV voice communication state 510. The PDSV voice communication state 510 
represents the processing necessary for the PBX 1 10 to maintain voice communication, 
30 which may involve switch control 202 operations such as analog-to-digital conversion 
and filtering, signaling and the like. If the call recipient answers using is a PBX phone, 
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the PBX 110 may also send a call-answered event comprising the extension of the call 
recipient's PBX phone to the same registered client that the off-hook plus dialed- 
extension event was sent. The PDSV voice communication generally continues until a 
calling or called party goes on-hook 528 and terminates the voice communication (state 
5 516). 

At nny time during the PDSV voice communications (state 510), the call in progress may 
be transferred to another device. If the PBX 1 10 is enabled with a VoIP protocol, for 
example, the PBX can transfer the call in response to a transfer command 534, e.g. a CTI 

10 message, with an identifier specifying the device to which the voice communication is to 
be redirected. If transferred to a VoIP client in the enterprise worker's PMIC, for 
example, the PBX 110 attempts to establish a VoIP session (state 512) and transfer the 
caller side of the communication to a VoIP device. In the session setup process 800 
associated with the session setup (state 512) illustrated in FIG. 8, the PBX 1 10 uses the 

15 identifier from the transfer command received (step 810) to determine in the transfer 

selection mode (step 820) where to forward the VoIP call. A transfer command including 
a universal resource (URI) designating the caller's PMIC, for example, causes the PBX 
1 10 to issue (step 840) a session request message, e.g., a SIP INVITE, to a VoIP client in 
the caller's PMIC. If the PBX 1 10 receives a SIP OK message 542 in response to the 

20 session request message, the SIP OK testing (step 850) is answered in the affirmative and 
SIP VoIP session (state 514) replaces the prior PDSV communication between the 
caller's phone and PBX 110. The PBX 1 10 may also be adapted to transfer calls to other 
resources (step 830) including other PBX phones or external phones, for example. 

25 After the SIP VoIP session is established (state 514), a participant in the session may 
terminate the session and effectively end the call (state 516) by issuing a VoIP 
termination message such as a SIP BYE message 544. In the alternative, the participant 
may transfer the call back to a phone set (state 510) using a transfer command 536 
including the appropriate phone extension. 

30 
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Any time during the PDSV voice communications (state 510), the call in progress may be 
placed on hold (state 518) by a hold PDSV operation code from the user's PBX phone or 
by a hold command 524 received by the PBX 1 10 from the user's PMIC 428 via the 
network 150. Similarly, the call may be taken off hold in response to the appropriate 
5 operation code or an un-hold command from the user's PMIC 428. 

In addition to outgoing calls discussed above, the PBX 110 is also enabled to facilitate 
incoming calls. When a call 540 is directed to a user phone 130-132 from either another 
PBX user phone 130-132 or external PSTN line, the PBX 1 10 transitions into the initial 

10 call receiving state 508. As illustrated the call receiving procedure 900 of FIG. 9 

associated with the initial call receiving state 508 of FIG. 5B, the PBX 110 transmits 
(step 910) the incoming connection request to the recipient's phone in the form of a ring 
signal. The PBX 1 10 in the preferred embodiment also transmits (step 920) an incoming- 
call event, e.g. a CTI message, via the network 150 to notify the recipient's PMIC of the 

15 connection request. 

In the preferred embodiment, the incoming call may be answered at the recipient's PBX 
phone or by way of a CTI answer event received by the PBX 110 from the user's PMIC 
via the network 150. Upon receipt of an off-hook signal 570 from the PBX phone, the 

20 PBX 1 10 transitions to the call answered (state 552) illustrated in more detail in the call 
answered process 1000 of FIG. 10. As shown, receipt of the off-hook signal (step 1010) 
causes the PBX 1 10 to transmit (step 1020) a first call-answered event, e.g., a CTI 
message, notifying the recipient's PMIC that the call has been accepted at the associated 
PBX phone. If the call is also initiated from a PBX phone 130-132 within the PBX 

25 system 100, internal-caller testing (step 1030) is answered in the affirmative and the PBX 
110 generates a second call-answered event transmitted (step 1040) to the caller's PMIC. 
The second call-answered event, e.g. a CTI message, notifies the caller's PMIC when the 
call is answered by the call recipient at the recipient's PBX phone or other device. 
Subsequent PDSV voice communications in state 554 are analogous to that discussed 

30 above in context of PDSV voice communication state 510. 
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When the incoming call is answered at the call recipient's PMIC, the PBX 110 generally 
receives an answer command accompanied by a transfer command from the PMIC. The 
transfer command includes a URI designating the user's PMIC or a SIP user agent therein 
and the PBX 110 transitions to the PBX's VoIP session setup state 556 consistent with 
5 the VoIP session setup state 514 discussed above. If the session request message issued 
by the PBX 1 10 is accepted, the PBX transitions into the PBX's VoIP session (state 558) 
and the PDSV voice communication terminated. The recipient may subsequently transfer 
586 the call between the PDSV voice communication (state 554) and the VoIP session 
(state 558) in the manner described above. 

10 

If the transfer command 590 received while in the initial call receiving (state 508) 
includes a URI designating a phone, computer, or user agent other than that of the 
recipient, the PBX 1 10 effectively transfers the call to the other device and returns to 
monitoring the phone status (state 502). 

15 

Illustrated in FIG. 1 1 is a state diagram characterizing the PMIC for extending the scope 
and control of a PBX system and extending the scope of the presence sensing into the 
telephonic domain. The PMIC process 1 100 is preferably embodied in one or more user 
computers within an enterprise that may have a new or existing PBX system consistent 
20 with operations discussed above. Each user computer 140-142 is adapted to execute the 
PMIC process 1 100, thereby making them PMICs. The plurality of PMICs that 
interoperate with one another and the PBX 1 10 constitute a PMIC system. In general, 
there is a one-to-one relationship between a PMIC and an enterprise worker's PBX 
phone. 

25 

A PMIC generally monitors (state 1 102) the IP network 150 for messages transmitted by 
the PBX 1 10 as well as other PMICs in the enterprise. The messages from the PBX 1 10 
generally fall into one of two categories, namely, call-placed messages indicating that the 
PBX phone 130-132 with which the PMIC is associated is being used to place a call or 
30 incoming call messages indicating that the associated PBX phone is receiving a call from 
either another PBX user phone or external line. 

15 



When the PBX phone associated with the PMIC is used to place a call, the PMIC 
receives the off-hook event 1130 generated by PBX 102 and transitions into the on-phone 
presence-state (P-S) processing (state 1104). The P-S processing (state 1104) is 
5 illustrated in greater detail in the on-phone P-S processing method 1200 of FIG. 12 A. As 
illustrated, the PMIC consults (step 1210) its local subscriber table 432 to identify the call 
recipient's presence-state subscribers. A P-S subscriber is party that has registered to 
receive notice of a co-worker's online presence and or telephonic availability. If one or 
more subscribers are identified (step 1220), an on-phone event, e.g., a SIP message, is 
10 t transmitted (step 1230) to each subscriber to indicate that the party whose presence- state 
is being monitored has picked up the PBX phone. Referring to FIG. 1 1, the PMIC then 
indirectly monitors the telephonic communications (state 1106) by listening for any CTI 
events signifying a change in the ongoing telephonic communication. 

15 When the PBX phone associated with the PMIC receives a call, the PMIC receives an 
incoming-call event 1 140 and transitions to a call-routing mode (state 1 1 10) in which the 
PMIC consults its routing logic 430. The routing logic 430 is customized by the user and 
prescribes the action to be taken in response to an incoming call. In the preferred 
embodiment, the PMIC is adapted to perform one or more of the following: (1) permit the 

20 incoming call to ring at the user PBX phone without intervention, (2) transfer the 

incoming call to the user's PMIC, (3) transfer the incoming call to another device, e.g., 
the user's cell phone, (4) transfer the incoming call to another PBX phone, or (5) transmit 
an instant message to the caller. In the preferred embodiment, the user can define 
individual call-routing rules that prescribe how to respond to the incoming calls as a 

25 function of when the call is received, the telephone number or extension of the caller, the 
time of day and day of week, and the user's presence-state, for example. 

If the routing logic 430 prescribes no action and the call recipient answers the PBX 
phone, the PMIC receives an off-hook event 1 142 from the PBX 1 10. The PMIC process 
30 1 100 advances to an on-phone presence-state (state 1 1 12), as illustrated in FIG. 12A, as 
well as a concurrent media session (CMS) setup (state 1 1 14). The on-phone presence- 
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state (state 1 1 12) is consistent with the on-phone P-S processing (state 1 104) described 
above. As illustrated in the CMS setup procedure 1300 of FIG. 13 associated with the 
CMS setup (state 1 1 14), the PMIC uses the extension and or phone number from the off- 
hook event received (step 1310) to determine (step 1320) whether to initiate a media 
5 session concurrently with the telephonic communication that began when the phone was 
answered. A media session as used herein refers to a network-domain dialogue between 
the caller and call recipient established and maintained separate from the telephonic 
communication. In the preferred embodiment, the concurrent media session may take 
one of more of the following four forms: (1) a "message session" such as a SIP instant 
10 message, (2) a "text session" such as a SIP text chat session, (3) a "multimedia session" 
in which a SIP video or audio is exchanged, (4) a document exchange session, or (5) 
computer GUI interface sharing such as a window-based operating system's "desktop 
sharing." 

15 

Referring again to FIG. 13, the CMS testing (step 1330) is answered in the affirmative if, 
for example, call recipient's PMIC is configured to automatically attempt to initiate a 
CMS with all incoming PBX calls, or if the incoming call is from a PBX extension 
included in a group of one or more numbers pre-selected or otherwise approved by the 

20 call recipient.. The selection of the type(s) of CMS(s) to be established are determined 
from user-defined CMS configuration parameters maintained by the call recipient's 
PMIC handler 434. A CMS configuration parameter may be set with a default value so 
that a text chat session or a video session, for example, is automatically established in 
response to a telephone call. Independent of the initial session type, either user may then 

25 manually escalate to a supplemental CMS including document share, screen share mode, 
or video session, for example. The one or more CMSs are initiated with a session 
request, e.g., a SIP message, directed from the recipient's PMIC to the caller's PMIC or 
other SIP conference calling center, e.g., a multi-point control unit known to those skilled 
in the art. If the session request is accepted with a SIP OK message, the session-request- 

30 answered testing (step 1360) is indicated in the affirmative and the media session 

launched (step 1370) between the PMICs of the caller and recipient. In the preferred 



17 



embodiment, the CMS may be maintained or terminated separate and independent of the 
telephonic communication. Alternately, the CMS sessions could be terminated with the 
telephone communication session ended. 

Referring again to Figure 1 1, the PMIC process 1100 proceeds to passively monitor (state 
1 106) the network 150 for any events signifying a change in the ongoing telephonic 
communication. When the phone is hung up, for example, the PBX 110 transmits an on- 
hook event 1 136, e.g. a CTI message, to the recipient's PMIC that causes the PMIC 
process 1 1 10 to transition to the off-phone P-S processing (state 1 108). In the off-phone 
P-S processing of FIG. 12B, associated with the phone P-S state 1 108, the PMIC consults 
(step 1250) its local subscriber table 432 to identify the call recipient's current presence- 
state subscribers. If one or more subscribers are identified, the subscriptions testing (step 
1260) is answered in the affirmative and each subscribers sent (step 1270) an P-S status 
event, e.g., a SIP message, indicating the availability status of the call recipient 
immediately prior to going off-hook to answering the call. In an alternate embodiment, 
the availability status sent to each subscriber is on-line status. 

Apart from the monitoring function (state 1 106), the PMIC in some embodiments is also 
adapted to issue commands to the PBX 1 10 to alter the telephonic communication 
20 involving the associated PBX phone. In the preferred embodiment, the caller may alter 
the ongoing telephonic communication by taking one of the following actions: (1) 
terminate the call, (2) place the call on hold, (3) transfer the call, or (4) establish a 
conference call with one or more additional parties. The user may terminate the call 
from the PMIC by issuing a terminate command 1 162, e.g. a CTI message, that instructs 
25 the PBX 1 10 to end (state 124) voice communications with the user' PBX phone. The 
user may also issue a hold command 1134A, e.g., a CTI message, to temporarily 
discontinue the voice communications, after which the PMIC process 1 100 resumes 
passively monitoring (state 1106) the PBX 110. An analogous release-hold command 
1 134B may be issued by the user from the PMIC to remove the hold and enable voice 
30 communication. 
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Prior to ending the call, the user may also transfer the call from the PBX phone to another 
device by issuing a transfer command to the PBX 1 10. Depending on the identifier — 
URI, phone number, or extension — the PBX 1 10 may transfer the call to the user's 
PMIC, the user's cell phone, or another PBX extension, for example. When transferred 
5 by command 1 144 to the user's PMIC, the PMIC process 1 100 transitions to the PMIC 
session setup (state 1 1 16) in which the PMIC and PBX 1 10 exchange SIP INVITE and 
OK messages necessary to establish a VoIP session (state 1118) to replace the telephonic 
communication. While in the PMIC VoIP session (state 1118), the user acting through 
the PMIC GUI 436 can issue a PBX phone transfer command 1 148 to restore the 
10 telephonic communication (state 1 106), issue a SIP BYE 1 158 message to end the call 
(state 1 124), or issue an external-device transfer command 1 160 causing the PBX 1 10 to 
forward (state 1 120) the call to any device specified by the user. 

In addition to permitting an incoming call to be answered at the user's PBX phone, the 
15 call routing logic 430 may be configured to cause the PMIC in the call routing mode 
(state 1 1 10) to automatically respond with one or more of the following actions: (1) 
transfer an incoming call to the PMIC session setup (state 1116), transfer or forward the 
call to an external device (state 1112), or (3) reply with a message to the caller's PMIC 
using an Instant Message. In the preferred embodiment, routing logic 430 is configured 
20 by the user to direct calls depending on the caller's identification, the time, and the date, 
for example. 

The flow diagrams in FIGS. 14 through 20 discussed below illustrate various aspects of 
the PMIC processing 1 100 of the preferred embodiment. These figures are provided by 
25 way of example and not limitation. 

Illustrated in FIG. 14 is flow diagram depicting the method of distributing telephonic 
presence-state notices in the PBX system 100. Prior to configuring a user's PMIC to 
perform P-S notification, a user generally transmits a registration command to the PBX 
30 1 10 to associate the user's PMIC with the user's phone extension. This causes the PBX 
1 10 to transmit subsequent event messages pertaining to the user's PBX phone to the 
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user's PMIC. The class of events transmitted by the PBX to a PMIC generally includes, 
but is not limited to: off-hook plus digits events, off-hook plus extension events, 
extension-dialed events, transfer events, incoming-call events, and answer events. In the 
following examples illustrated in FIG. 14 through FIG. 20B, the first user PBX phone 
5 130 is identified by extension number xl234, the first user PMIC 140 identified by URI 
1234@proxy.com, the second user PBX phone 131 is identified by extension number 
x5678, and the second user PMIC 141 identified by URI 5678@proxy.com. 

The registration command 1402 causes the PBX 1 10 to send to the first user's PMIC 
10 various CTI events relating to the first user's phone 130. The registration command 1402 
may require that the first user 120 enter a user identifier and password, although other 
forms of authentication may be implemented. Similarly, the PBX 1 10 is able to associate 
CTI commands from this first user's 120 PMIC 140 with the phone 130 extension. 

15 At some later point in time, when the first user 120 picks up the phone 130, an off-hook 
signal 1404 is relayed by the PBX 1 10 to the first user PMIC 140 in the form of an off- 
hook event, preferably a CTI off-hook message 1406. Receipt of the CTI event 
stimulates the PMIC 140 to automatically change the presence-state for the first user to 
"on-phone" state. As prescribed by the on-phone presence-state processing 1200, the 

20 PMIC 140 consults (method 1200) its subscriber table 432 and transmits a notify message 
1408, 1410 to all subscribers 121, 122 by way of the associated PMICs 141, 142. The 
notify message is preferably a SIP on-phone message advertising the change in the first 
user's telephonic availability. 

25 When the first user completes the call, the on-hook signal 1412 from the first user phone 
130 causes the PBX 1 10 to send the first user's PMIC 140 an on-hook event 1414, 
preferably a CTI message. As prescribed by the off-phone present state processing 1250, 
the PMIC 140 consults (method 1250) the subscriber table 430 and notifies all 
subscribers 141, 142 of the change in the presence state by way of a SIP notify messages 

30 1416, 1418. In the preferred embodiment, the presence state indicated by the SIP notify 
messages 1416, 1418 is the presence state that existed just prior to the placement of the 
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call. In an alternative embodiment, the presence state sent when the user goes off-phone 
may be "on-line" notice. The selection between the two embodiments might be a user- 
manageable setting. 

One skilled in the art will appreciate that the linkage between the PBX phone operation 
and the presence state is performed entirely within the associated PMIC endpoint itself. 
Moreover, the presence-state for the user is changed automatically based on receipt of a 
CTI event without the user manually changing his or her presence state via GUI 
interaction or other manual input. A principal advantage of this method of presence 
integration is that it can completely coexist and fully interoperate with all other presence 
servers, presence collection/distribution servers, and any other SIP proxy servers that 
might be operational within the network 150. The proposed method is also highly 
scalable, since it each PMIC is only responsible for the presence management of its 
associated user PBX phone. 

In some embodiments, the PBX 1 10 is both the source of CTI events and recipient of CTI 
commands. One skilled in the art will recognize, however, the a PBX may employ a 
separate and external CTI server (not shown) that provides fan-out capability, user 
authentication, and other CTI management tasks, as well as protocol translation between 
the PBX and the CTI client, for example. 

Illustrated in FIG. 15 is a flow diagram demonstrating the use of a networked 
intermediate server with which the PBX and one or more PMICs may interoperate. The 
CTI server 1502 is adapted to relay messages between the PBX 110 and one or more 
25 PMICs using CTI and/or extensible Markup Language (XML) protocols between the 

CTI server 1502 and the one or more PMICs 120, 121. The proxy server 1502 relays CTI 
messages between the CTI server 1502 and the PBX 1 10 using the CSTA CTI protocol, 
for example. Other protocol translations might also be possible including, but not limited 
to, HTTP using Get or Post messages via a dedicated IP socket, or SIP using textual 
30 information transmitted with SIP MESSAGES sent between the CTI server 1502 and a 
PMIC. 

21 



10 



15 



20 



As illustrated in FIG. 15, a first user PMIC 140 transmits a registration command 1510, 
preferably a CTI or XML message, to the CTI server 1502. The registration command 
1510 comprises the extension number of the first user phone 130 and enables the CTI 
5 server 1502 to create an association between the first user PBX phone 130 and the first 
user PMIC 140. When the first user phone 130 is used to place a call or answer a call, the 
PBX 1 10 relays the off-hook signal 1512 to the CTI server 1502 in the form of a CTI off- 
hook event 1514. The server 1502, in turn, forwards the CTI/XML off-hook event 1516 
to the first user PMIC 140. Reception of CTI off-hook event 1516 stimulates a change in 

10 first user's presence state that is propagated to any subscribers via an off-phone 
notification event 1518, e.g., a SIP message. Similarly, an on-hook signal 1520 is 
transmitted to the CTI server 1502 in the form of a CTI on-hook event 1522, then 
transmitted to the first user PMIC 140 in the form of CTI/XML off-hook event 1524. 
The first user identifies (step 1250) the presence state subscribers to be sent a SIP notify 

15 event 1526. One skilled in the art will appreciate that the presence state management in 
the one or more PMICs of FIG 14 is functionally equivalent to those in FIG. 14, 
independent of whether the event messages originating from the PBX 1 10 are sent 
directly to the PMICs or indirectly via the CTI server 1502. 

20 Illustrated in FIG. 16A is a flow diagram demonstrating the procedure for establishing a 
first category of CMS between calling parties. In this example, a CMS in the form of a 
SIP session is automatically initiated between a caller and recipient in the PBX system 
100 in response to a telephone call. For purposes of demonstration, let the first user 
phone 130 have extension number xl234 and the second user phone 131 have extension 

25 number x5678. When the first user 120 depresses Dual Tone Multi Frequency (DTMF) 
keys on the PBX phone 130 to call the second user 130, an off-hook signal 1602 
comprising the call recipient's extension is transmitted to the PBX 110. In addition to the 
ring signal 1606 transmitted (step 720) to the second user's phone 131, the PBX 1 10 also 
generates (step 730) an extension-dialed event 1604 to the caller's computer, PMIC 140, 

30 as notice that a call has been placed to the extension number x5678. Similarly, the 
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second user's PMIC 141 is notified via the incoming-call event 1608 of the incoming call 
from extension xl234. 

If the incoming call is answered with off-hook signal 1610, the PBX 1 10 puts the first 
5 user phone 130 and second user phone 131 in telephonic voice communication 1616. 
The CTI-enabled PBX 1 10 also responds to the off-hook signal 1610 with a first call- 
answered event 1612 transmitted (step 1020) to the second user's PMIC 141 as well as a 
second call-answered event 1614 transmitted (step 1040) to the first user's PMIC 140. 

10 In response to the first call-answered event 1612, the second user's PMIC 141 
automatically initiates (step 1650) a media session, preferably a SIP chat session, 
concurrent with the telephonic voice communication 1616. The process of initiating 
(step 1650) the media session is set forth in greater detail in CMS setup 1 1 14 of FIG. 13. 
In this example, the media session is a SIP session including a simple SIP:MESSAGE 

15 message sent from second user's PMIC 141 to the first user's PMIC 140. In order to 
generate this SIP message 1620, in the preferred embodiment, the second user's PMIC 
141 derives the SIP URI of the first user's PMIC 140 in accordance with a SIP dial-plan. 
The dial-plan associates an extension, e.g., abed, included in an event message with a SIP 
URI, e.g., SIP:abcd@someproxy.com. In this manner, the second user PMIC 141 

20 extracts the extension number 1234 from the incoming-call event 1608 and generates a 
SIP MESSAGE transmitted to SIP: 1234@proxy.com. Other suitable dial-plans that allow 
the call recipient's PMIC to deduce the caller's URI from the calling extension are also 
possible. For example another dialing plan might associate extension 1234 with 
SIP:user91234@proxy.com where user 1234's PMIC has this SIP URL 

25 

After the SIP exchange is completed with SIP OK 1622, SIP text messaging windows are 
open on both first user's PMIC 140 and second user's PMIC 141, thereby allowing the 
first user 120 and second user 121 to text chat with one another concurrent with the voice 
communication 1616. One skilled in the art will appreciate that there is no need for the 
30 first user 120 or second user 121 to appear on each other's contact lists, nor a need for 
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either user to lookup an IP address or SIP URL Instead, the SIP session is established 
automatically based on the PBX call. 

Illustrated in FIG. 16B is a flow diagram demonstrating a second procedure for 
5 establishing a CMS between calling parties. In this example, the various signals, CTI 
event messages, and SIP messages in FIG. 16B are replicated from FIG. 16A beginning 
with the off-hook plus dialed number signal 1602 through the SIP MESSAGE 1620. 
Here, however, the presence of the SIP MESSAGE 1620, and the corresponding SIP: 
OK, has established a line of communication between first user 120 and second user 121 

10 that may be exploited to open additional forms of communication. After the SIP session 
signified by SIP MESSAGE 1620 has been between established, either the first user 120 
or the second user 121 may escalate the interaction to other forms of supplemental CMS 
using built-in capabilities of RTC, for example. In the preferred embodiment, either call 
participant may establish a supplemental CMS, e.g., a document exchange or a screen 

15 sharing session, that runs in parallel to the SIP:MESSAGE 1620. The supplemental CMS 
1624 may be manually selected (step 1652) by a user via the user's PMIC GUI 436 or 
other form of selection input device. 

Illustrated in FIG. 16C is a flow diagram demonstrating a third procedure for establishing 
20 a CMS between calling parties. Here, the various signals, CTI event messages, and SIP 
messages are replicated from FIG. 16A beginning with the off-hook plus dialed number 
signal 1602 through the SIP MESSAGE 1620. In this example, the first user 120 and 
second user 121 have desktop video cameras used by the CMS handler 434 of each user's 
PMIC 140, 141 to automatically setup (step 1654) a supplemental CMS such as video 
25 session 1626 with the primary CMS session 1620. The call recipient's CMS handler 434 
automatically issues an additional SIP INVITE containing video session description 
protocol (SDP) information. In the preferred embodiment, the video session is a user- 
manageable setting, thereby allowing a call recipient to configure the CMS handler 434 
to: (1) automatically enable and start the camera for every call, (2) fully disable the 
30 camera to prevent the camera from starting, (3) manual enable the camera to start at the 
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discretion of the user, or (4) selectively enable the camera to start depending on the caller 
identification, i.e., caller ID. 

As illustrated in more detail below, the integration of a CTI client capability into a PMIC 
5 permits the user to execute standard telephone set control functions from the individual's 
computer. In the preferred embodiment, the PMIC is adapted to transmit PBX call 
control commands including, but not limited to, make-call commands to initiate a call, 
answer-call commands to accept an incoming call, hold-call commands to temporarily 
pause an on-going call at the PBX, transfer-call commands to redirect a call between the 
10 PBX phone and user PMIC or other device, conference-call commands to establish a call 
with three or more parties, and forward-call commands to direct a call to a device 
specified by the user. 

Illustrated in FIG. 17 is a flow diagram demonstrating a PBX-supported call initiated 
15 from a PMIC. First, the user enters a destination telephone number into the user's PMIC 
GUI and activates a make-call routine in the PMIC controller. The PMIC issues a make- 
call command 1702 that causes the PBX 1 10 to issue a ring signal 1704 to the user's 
phone 130. After the handset is picked up and an off-hook signal 1706 transmitted, the 
PBX 110 places the call to the destination number corresponding to second user phone 
20 131, for example, via a ring signal 1708. When the second user phone 131 is answered 
and an off-hook signal 1710 transmitted, the parties are enabled for telephonic voice 
communications 1712, 1714. In another embodiment, the caller's PBX phone 130 
automatically enters a hands-free speakerphone mode and the recipient called 
immediately after the destination number is entered at the PMIC 140. 

25 

Illustrated in FIG. 18A and FIG. 18B are flow diagrams demonstrating an on-going 
communications being transferred between a user PBX phone and the associated PMIC. 
In this embodiment, the PMIC is adapted to interoperate with a PBX 1 10 enabled with 
SIP or other VoIP protocol in addition to CTI client functionality. This PBX system, 
30 referred to as a SIP-PBX, has native SIP capabilities including the ability to make and 
receive SIP voice calls. 
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As illustrated in FIG. 18 A, an enterprise worker may transfer an on-going call on the 
PBX phone to the user's PMIC. At any time during a telephonic voice conversation 
1802, 1804 between the first user phone 130 and the second user phone 131, a user may 
5 transfer the call from to his or her PMIC 141 by issuing a PMIC transfer command 1806, 
preferably a CTI message, comprising the identifier of the device to which to transfer the 
call. In the case of a PMIC 141 enabled with a SIP user agent, the transfer command 
1806 may include the SIP URI used by the PBX 1 10 to execute a call transfer to the 
PMIC SIP voice client. When the SIP INVITE 1808 to 5678@proxy.com is accepted by 
10 the PMIC 141 by means of a SIP OK message 1810, the PBX 1 10 bridges the first leg of 
the conversation 1814 with the first user phone 130 in the PDSV domain with the second 
leg of the conversation 1816 with the second user PMIC 131 in the SIP domain. In the 
preferred embodiment, the SIP URI is derived from extension number of the user phone 
with which it is associated. 

15 

As illustrated in FIG. 18B, the second user 121 may at any time transfer the SIP domain 
call 1816 directed to the second user PMIC 141 back to the second user PBX phone 141 
A PBX phone transfer command 1818, e.g. a CTI message, comprising the 1 10 second 
user's phone extension, number x5678, is issued by the second PMIC 141 to the PBX 
20 1 10. Upon receipt, the PBX 1 10 terminates the SIP session with a SIP BYE message 
1820 and enables the PDSV voice communication 1826 between the PBX 110 and the 
second user phone 131. 

As illustrated in FIG. 19, a PMIC may also be used to answer an incoming call destined 
25 to a PBX phone independently of the user's PBX phone. In response to an incoming call 
1902, the PBX 1 10 in the preferred embodiment transmits a ring signal 1906 an 
incoming-call event 1908, e.g. a CTI message, to the call recipient's PMIC 141. The 
second user 121 may then click an answered button in the PMIC GUI causing it to issue 
an answer command 1910 and transfer command 1912. The transfer command 1912 
30 comprises the identification of the device to which the call is to be forwarded. The 

identification of the PMIC 141 is the SIP URI, SIP:5678 ©proxy. com. In response, the 
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PBX 110 issues a SIP INVITE message 1914, to which the PMIC 141 automatically 
responds with a SIP OK message 1916. The subsequent conversation between the caller 
120 and recipient 121 includes PDSV domain voice 1920 between the caller 120 and SIP 
PBX 1 10, and SIP domain VoIP 1922 between the SIP PBX 1 10 and recipient's PMIC 
5 141. 

Illustrated in FIG. 20A and FIG. 20B are flow diagrams demonstrating an incoming call 
to a PBX phone being automatically processes by an associated PMIC without user 
intervention. In FIG. 20 A, the PMIC answers an incoming call to a user's PBX phone 
10 and then forwards the call to another device previously specified by the user. 

In response to an incoming call 2002, the PBX 1 10 in the preferred embodiment 
transmits ring signal 2006 to the second user phone 131 and an incoming-call event 2008 
to the call recipient's PMIC 141. Upon receipt of the incoming-call event 2008, the 

15 second user PMIC 141 implements call routing processing (state 1110) that dictates how 
this call is to be treated. If the call routing logic 430 of FIG. 4B indicates that the call . 
should be transferred to another device, the second user PMIC 141 issues an answer-call 
command 2010 preventing the PBX 110 from forwarding the call in accordance with its 
no-answer procedure, e.g. voice mail 206. The second user PMIC 141 also issues to the 

20 PBX 110 a call-transfer command 2012 identifying the destination device to which the 
call is to be forwarded, e.g., device ABCD. The destination device may be another PBX 
extension, a PSTN telephone, or a SIP user agent. 

The call routing logic 430 in the preferred embodiment comprises user-managed 
25 preferences include forwarding criteria and the action to be taken when the forwarding 
criteria are satisfied. These criteria may include the phone number or extension of the 
calling party and the time-of-day and date, for example. The call routing logic 430 may 
dictate that (1) on Wednesday evenings the call should be answered and transferred to 
PBX phone extension number x6789, on (2) Thursday evenings the call should be 
30 answered and transferred to John@acme.com, and (3) at all other times, the call is not 
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answered by the PMIC, thereby allowing the PBX 1 10 to automatically forward to call 
voicemail 206 if not answered. 

The call routing logic 430 in some embodiments may also depend on the presence state 
5 of its user. For example, if a user's presence state is set to "away," determined either via 
manual operation or automatically in the absence of keyboard activity for a period of 
time, the call routing logic 430 may be configured to forward to an incoming call to the 
extension of an administrative assistance. Similarly, an incoming call might be directed 
to the SIP user agent of another enterprise colleague selected by the user, thereby 
10 providing an alternative point of contact while the user is unavailable or out of the office. 
In the preferred embodiment, the call routing logic 430 is in the form of a script created 
by the user, although it may also be configured via a graphical and or menu-based 
interface on the PMIC GUI 436. 

15 The call routing logic 430 of a PMIC in some embodiments also includes the SIP text 
messaging and document transfer capabilities as part of the call treatment for incoming 
and outgoing calls at the PBX phone. Illustrated in FIG. 20B is a flow diagram 
demonstrating an instant message being transmitted by a PMIC in response to an 
incoming call. The PBX 1 10 responds to incoming call 2002 with ring signal 2006 and 

20 an incoming-call event 2008 sent to the call recipient's PMIC 141. Upon receipt of the 
incoming-call event 2008, the second user PMIC 141 implements call routing processing 
1110 that dictates how this call is to be treated. When configured accordingly, the second 
user's PMIC 141 transmits an instant message 2020 from the user's PMIC to the caller's 
PMIC 140. The caller's SIP URI, SIP: 1234@proxy.com, is derived from the caller's 

25 extension, number xl234, learned by the second user's PMIC 141 from the preceding 
incoming call event 2008. 

The instant message may include a standardized greeting or a customized Instant 
Message including information specifically intended for the caller about. A person may, 
30 for example, generate a personal message including the anticipated return time or an 
alternate contact number. Similarly, the call routing logic 430 in some embodiments is 
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adapted to transmit a document that may contain text, graphics, spreadsheet, or other 
information of interest to the caller in response to an incoming call directed to a specific 
PBX extension. 

5 After the instant message 2020, the incoming call may further processed in any number 
of ways defined by the call routing logic 430. In this example, the second PMIC 141 
causes the PBX 1 10 to transfer the incoming call to device ABCD using transfer 
command 2022. 

10 In some embodiments, the caller's PMIC may also be configured to respond to the call 
recipient's instant message with another instant message sent to the call recipient's PMIC 
141. For example, when the second user 121 receives a telephone call from extension 
number xl234, the call routing logic 432 generates the appropriate URI and sends an 
instant message to SIP:SecondUser@pda.com to inform the second user 121 that the first 

15 user phone 131, i.e., extension number xl234, had called. The call routing logic 430 may 
be tailored to inform a call recipient of the call and the time of the call. 

The call routing logic 430 may also be configured to automatically send an instant 
message when an outbound call is placed from the PBX phone associated PMIC. A 
20 specific SIP emergency message, for example, may be sent to a pre-selected SIP user 
when the Emergency 91 1 number is dialed. 

Illustrated in FIG. 21 is a functional block diagram of a user PMIC with a plurality of 
selectable SIP user agents. In addition to Microsoft's RTC SIP client 424 and a CTI 

25 client 420 discussed above, a PMIC 2100 may further include one or more additional SIP 
instant messaging applications such as a SAMETIME client 2102 by IBM Lotus Corp. 
and/or any other commercial SIP User Agent Client The user may select one of the 
plurality of SIP client via PMIC GUI 436, for example, by entering a user-selectable 
parameter causing the SIP/IM selection module 21 10 to use the selected SIP client for 

30 subsequent IM exchanges. To aid in the selection, the various features supported by each 
individual SIP client may be indicated as present or not present, or selectable and non- 
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selectable. As with other GUIs, the features that are not present in a particular client may 
be indicated by representing the feature in greyed-out text or icon form. To the degree 
that two or more SIP clients support common functionality, in the preferred embodiment 
the user experience is identical and independent of the SIP client selected. 

5 

Illustrated in FIG. 22 is a CTI server with which the present invention may be made to 
interoperate with one of a plurality of different types of PBX systems. The CTI server 
2200 in this embodiment comprises a plurality of PBX interfaces from which the network 
administrator may choose. Using the PBX selection 2208, for example, the system 

10 administrator may configure the CTI server 2200 to use either PBX- A interface 2202, 
PBX-B interface 2204, or PBX-C interface 2206, depending on the hardware and vendor 
requirements of the PBX 1 10. CTI server 2200 capable of communicating with multiple 
types of PBXs using a single common CTI interface 2210 protocol to/from a CTI client 
are available from Genesys Telecommunications Laboratories, Inc. of San Fransisco, CA, 

15 for example. In this manner, the PMIC is generally able to provide the functionality of 
the several embodiments in a manner independent of the type PBX system or vendor. 

Although the description above contains many specifications, these should not be 
construed as limiting the scope of the invention but as merely providing illustrations of 
20 some of the presently preferred embodiments of this invention. 

Therefore, the invention has been disclosed by way of example and not limitation, and 
reference should be made to the following claims to determine the scope of the present 
invention. 
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